Increasingly, developers are embedding operating systems, such as Windows CE, into many different types of computerized products, including set-top boxes, gaming systems, bar-code scanners, and factory automation systems. As Windows CE has grown, so too has the need for "off-the-shelf" software development tools. Although many tools and "off-the-shelf" software kits have been on the market for saving device design time, leading to speedy device development, no fast testing system or method existed to verify compatibility of these new products, especially at the final stages of device development.
Traditionally, only two operating system device testing options have been available: (1) in-house writing of the test code, or (2) out-sourcing the custom code development to another firm. To complete the testing project in-house, Original Equipment Manufacturers (OEMs) must spend months training their staff, more months developing the test codes, and yet even more months of preparation before their product can be tested using such codes. Likewise, an out-source custom code development house would spend months writing the code. Thus, both options are time-consuming and, therefore, costly.
In related art quality assurance device testing systems, several network protocols are used which suspend program execution while waiting for an acknowledgment of a sent message. For example, Transmission Control Protocol (TCP), at a low level, blocks program execution until certain sent messages are acknowledged by the remote end of a "connection." Most protocols are implemented in an O/S-independent manner. As such, sent messages requiring an acknowledgment must be maintained in a list which cross-references the identification of a sent message with an execution thread, such thread waiting for such acknowledgment. Such related art systems follow a lengthy sequence: creating a message ID prior to sending the initial message; adding an element in a list associating the execution thread with the message ID; sending the message; blocking the sending thread of the execution until the receiving code unblocks it; acknowledging, by the remote process, the sent message by sending back an ACK message containing the original message ID; receiving ACK message by the sending machine; parsing for the message ID of the originally sent message; looking-up the message ID in the list; determining which execution thread to release from the list; and finally, releasing the original sending thread of execution to continue program execution.
These time consuming operating system device testing options have created a long-felt need for a consolidated testing system and method, utilizing a protocol acknowledgment between homogeneous systems, for improving product quality, imparting time and cost savings of many person-months, and streamlining of the product development process. In particular, a system and method for testing and validating devices having an embedded Windows CE operating system installed is needed to overcome the foregoing problem and thus provide a system and method which improves product quality, imparts time and cost savings of many person-months, and streamlines the product development process resulting in a fully automated design verification package for device designers. In particular, a need exists for a system which uses O/S-provided events, an O/S-internally-maintained event list, and an O/S-internally-maintained blocking threads (i.e. sending threads) list. Thus, unlike related art protocol acknowledgment methods, several steps need to be eliminated (e.g., adding an element which associates the execution thread with the message ID in a list, cross-referencing the message ID in a list, and determining which execution thread to release from a list entry).
Thus, a code which is simpler, shorter, and less error-prone via an alternative method of processing ACKs would be beneficial where a plurality of actions could be executed upon reception of an acknowledgment message (e.g., multiple cross-referencing and attendant delays elimination, code for the reception of ACK which is largely identical with a single-thread case, priority data which need not be maintained in a sent message list if multiple threads are prioritized, and an ID list which need not be entirely scanned to determine a thread-release priority as an O/S restarts all threads with an appropriate priority). A beneficial system would also be able to implement multiple pending threads of execution which are waiting for an ACK message, the threads needing merely to use the O/S-provided function of waiting for an event handle which was embedded by the initial "send" in the protocol header. Likewise advantageous, multiple threads of execution should be triggered, without additional cross-reference processing, by an ACK for any message of a plurality of sent messages.